Micro controllers are known from the related art which have at least one microprocessor (computer core), an analog/digital (A/D) converter, a digital/analog (D/A) converter, a data bus, an address bus, a control bus, internal control elements (e.g., a read-only memory or a flash memory), and/or further components. This type of micro controller is, for example, part of a controller for a motor vehicle. The controller is used for control/regulation of technical processes in the motor vehicle of, e.g., the internal combustion engine, the transmission, the steering assembly, the chassis, etc. A control program for executing the control/regulation is stored in an internal or external control element of the micro controller. The control program is executable on at least one of the microprocessors.
More complex Micro controllers of a newer design have a debug logic as a further component. The debug logic is used during the development of the program that is executable on the at least one microprocessor of the micro controller and is used for improvement of the visibility of the processes running in the micro controller. With the aid of the debug logic, faults in the program can be recognized, localized, and removed from the program. The debug logic is connected to a data bus, an address bus, and/or a control bus of the micro controller. The debug logic can learn from the address bus which selected address range was accessed, from the data bus, which data is to be written into the selected address range or was read out of the selected address range, and, from the control bus, whether a write or read access is to be performed on the selected address range.
The debug logic additionally has a debug interface which can be connected to a debugger. The debugger is usually implemented as a conventional personal computer (PC) on which a debug program runs. With the aid of the debugger, the program execution on the microprocessor can be controlled and the status of the program and of the micro controller can be monitored. After completion of the program development, the debug logic is no longer necessary. However, because it is part of the micro controller, it is unavoidably taken along during the program execution time during the designated use of the micro controller, although it actually has no function.
The debug logic is connected to the microprocessor via an event line. The debug logic can, as a rule, trigger an exception, e.g., an interrupt. An interrupt is a signal which is sent from an input/output unit to the microprocessor when a fault has occurred or an intervention is required in order to terminate the input/output. An interrupt normally causes the execution of the current program to be discontinued and an interrupt routine to be executed.
Using a trace tool, which tracks and records the processes running in a micro controller, particularly in the microprocessor, during the development of a program executable on the microprocessor of a micro controller, is known from U.S. Pat. No. 5,809,293. However, making the processes visible with the trace tool reaches its limits, if, for example, a cache is positioned, between the trace tool and the microprocessor, in which values are temporarily stored during the program execution time and read out as needed. In this case, because the trace tool does not have access directly to the microprocessor, but only to the temporarily stored values, it does not know which commands are executed by the microprocessor and when. U.S. Pat. No. 5,809,293 suggests that, in such a case, a debug logic be used to support the trace tool and to enhance the visibility of the processes running in the micro controller.
A micro controller having a debug logic is known from U.S. Pat. No. 5,680,620 which is used to execute a reaping of input/output (I/O) ports. This can be necessary, for example, if an old program runs in a new hardware environment in which specific I/O ports are no longer present. A breakpoint is placed at the addresses of the I/O ports which are no longer present. The debug logic monitors the program execution during the program execution time. When access to one of these addresses is attempted, an exception is triggered and an exception routine is executed. In the course of the exception routine, the address of the I/O port no longer present is reaped onto the address of an I/O port present in the new hardware environment.
This method from U.S. Pat. No. 5,680,620 can also be used to allow execution of an old program in a new operating system environment. For example, if, unlike the old operating system, the new operating system allows access to an I/O port from multiple applications, the accesses to the I/O port cannot take place directly from an application—as was typical under the old operating system environment—but is controlled and coordinated via the operating system. In this case, each access to an I/O port triggers an exception, through which the access is routed to the operating system for coordination.
In the methods known from the related art, only legal accesses to the I/O ports are handled. In the framework of the known methods, the commands and/or the program are not monitored for possible faults. The known method therefore simply involves an expansion of the operating system.
Monitoring a stack of a micro controller by writing a pattern in a storage area at the edge of the stack during the startup of the micro controller and checking whether or not this pattern has been changed from time to time during the program execution time is also known from the related art. A change in the pattern indicates a stack overflow or a stack underflow. This type of monitoring of a storage area has the disadvantage, however, that it is relatively resource-intensive; in particular, it costs microprocessor computing performance and program memory. In addition, it is no longer sufficient for stack monitoring in modern Micro controllers to monitor a change in a pattern in a limited storage area at the edge of the stack, because, during the building of a stack frame, a jump over several addresses can also occur without the addresses in the intermediate space being altered. For this reason, the storage area at the edge of the stack to be monitored is selected to be ever larger, whereby the resources of the micro controller are greatly strained and the computing time increases. In addition, the known method does not recognize a stack overflow and/or a stack underflow until storage areas outside the storage area provided have already been accessed. The danger thereby arises that the program executable on the microprocessor will reach an undefined state even before the overflow or underflow of the stack area provided is detected and appropriate countermeasures can be introduced.